1. Technical Field
The invention relates to service management and service presentation systems, wherein measurement data regarding services delivered by Service Providers to customers are gathered and handled to compute and communicate service indicators defined in service level agreements and, in particular, relates to a method for managing the service levels provided by Service Providers.
2. Related Art
A Service Provider (SP) provides, hosts, or manages resources for its customers. A resource can be a server, a particular application on a server, a networking device, people in a help desk to answer users, people to fix problems, people to manage and change systems configuration and location, . . . etc. . . . or a complex solution made of multiple elements to accomplish or support a customer business process. The Service Provider and the customer can be different firms, or different departments in a large global enterprise where departments are organized as support services for other departments, e.g. Marketing, Research, Sales, Production.
Normally, a Service Level Agreement (SLA) is executed (i.e., signed) between a provider and a customer to define the role of each party and to remove any ambiguity from the business relationship. Such a SLA:                Identifies the parties involved in the agreement.        Describes the service to be provided, and identifies in a measurable and quantifiable manner indicators of the quality of the service on which obligations will be set, with a possible series of exceptions and stipulations in the way to calculate these indicators.        Defines the obligations, called Service Levels (SLs), to be met on the identified indicators, so that the expected quality of the delivered services is set in an un-ambiguous manner.        Defines the agreement period for which these obligations are set forward.        Pre-defines penalties to be paid/executed by the SP if the commitment(s) is (are) not met. If a commitment is exceeded, a reward can also be predefined, to be paid by the customer.        Also defines reporting policies, corrective actions, dispute resolution procedures, termination criteria, intellectual property.        
A SLA is encountered when considering utilities to be trusted “always-on” services such as providing water, electricity, gas, telephone, e-service (e.g., e-Business On Demand), etc. In fact, a SLA exists when a specific service offer including commitments is engaged with a customer.
By itself, a SLA does not bring any change in the level of service delivered. The Service Provider and/or the customer need to implement a Service Level Management (SLM) program that will actually result in higher levels of services. Indeed, a SLA only specifies the agreed criteria for determining whether or not a set of agreed service quality levels are met. When not met, the issue is to determine what caused the violation, maybe how to improve the service, or change the SLA or the provider. The Service Level Management begins with the development of new service levels for a new contract and continues throughout the life of the contract to ensure Service Level commitments are met and maintained.
The Service Level Management is commonly identified as the activities of:                negotiating, identifying and agreeing the measurable services that support the Business Process of a customer, and defining the SLA articulation in an offering for service with Service Level Objectives (SLO) also known as Service Level Targets (SLT),        monitoring resources used to deliver a service and capturing data on how well these resources perform from monitors or from logs,        calculating intermediate and high level Service Levels results or scores using the predefined service parameters formulae (called metrics) and taking into account all kinds of exceptions that can occur, assessing attainment versus commitments and possible penalties or rewards,        assessing impact of operational outages or degradations in terms of SLAs (services) and financial impacts, alerting in real-time of possible or effected outages, diagnosing problems for resolution, enforcing corrective actions wherever possible to regulate the delivery system and therefore try to proactively guarantee the achievement of obligations,        reporting to the provider and the customer on real numbers versus contractual numbers, and sealing final numbers to be used for rebates or rewards,        rebating to customers when commitments are not achieved, or rewarding the provider when commitments are exceeded, and        refining, improving and reviewing SLA definitions, service levels and services that support the customer's Business Process.        
Today, there are SLA Management Systems which are automated for managing SLAs such as IBM Tivoli Service Level Advisor, Computer Associates SLM, Digital Fuel or InfoVista. They are built to accomplish, at least, a minimum set of tasks such as capturing data from monitoring systems, and they participate or supply information to other service management activities such as alerting, enforcing or reporting.
However, these systems provide no complete answer to the service level management problem. Indeed, very often a piece of the solution used to support the customer business process which is managed by the Service Provider is coming from the customer, or is under the customer's responsibility (shared or not with the Service Provider). The means used by these systems do not automatically take such situations into account where an SLA is violated due to Customer's responsibility. In such cases, the result must be revised to reflect the true responsibility of the SP only after calculation by these systems.
In addition, when a SLA is violated, or when the SP is attempting to improve its delivered service, a lot of investigation can be done on monitoring data, and it has to take into account the problem expressed above. These SLA Management Systems do not provide any help on these tasks which can then be time consuming and not very efficient, or require the use of other complex and costly means to implement external tools for correlation between data and results.